The Real-time Transport Protocol (RTP) (see Schulzrinne et al., “RTP: A Transport Protocol for Real-Time Applications”, RFC 3550, incorporated herein by reference and available at http://www.ietf.org) provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services.
The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers.
For the multicast or broadcast data transport of streaming services in 3G networks RTP may be used. As mentioned above, the Real-Time Control Protocol (RTCP) provides means for monitoring and transporting control information on a delivered RTP stream.
Standard RTP/RTCP
RTP (and its companion protocol RTCP) have been originally designed for both unicast as well as multicast data transport (RTP reporting). Consequently, scalable algorithms for preventing feedback implosion and the corresponding mechanisms have been proposed. In the rest of this document it is referred to the latter as “the standard RTCP algorithm and mechanisms”, respectively.
The RTCP standard algorithm and mechanisms have been designed with the assumption of an underlying Any-Source Multicast (ASM) model, where every end system is allowed to send and receive data over the bidirectional transport channel.
Consequently, each participating end system receives the RTP data, as well as the RTCP sender reports (SR) and receiver reports (RR) of all participants. The reception of all RR allows each end system to estimate the number of participants of a session independently, and use this value to calculate the report time interval according to the RTCP standard algorithm. Furthermore, it provides a means for the end hosts to gather information about all participants, which might be useful for some applications like small group conferencing.
RTCP RR for Unidirectional Multicast Channels
The Source-Specific Multicast (SSM) model as described S. Bhattacharyya, Ed. “An Overview of Source-Specific Multicast (SSM)” (see RFC 3569, incorporated herein by reference and available at http//www.ietf.org) may be particularly suitable for use in conjunction with the 3GPP MBMS architecture as specified in 3GPP TR 23.846: “Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)”, V6.1.0, December 2003, incorporated herein by reference and available at http://www.3gpp.org.
The SSM multicast model introduces less complexity compared to ASM and allows for subscription-based access control. In SSM, each single end system is allowed to transmit data using a unidirectional multicast transport channel. Only those participants subscribed to this channel will receive the messages.
Unlike in ASM, RTCP receiver reports cannot be transmitted over this multicast channel. This limitation for the SSM may however be overcome by each receiver sending feedback over individual unicast transport channels to the sender and the sender reflecting these messages over the multicast channel, according to the specified Receiver and Sender Report bandwidth values.
SDP Bandwidth Modifiers for RTCP
The standard RTCP mechanisms scale the overall control traffic bandwidth to 5% of the RTP Session Bandwidth. For the target application scenario with a single sender, the fraction S of the RTP Bandwidth assigned for sender reports (SR) is 1.25%, while the fraction R equally shared by the end systems for receiver reports (RR) is assigned a value of 3.75%. In order to support assignment of differing allocations, the signaling of RTCP bandwidth modifiers within the Session Description Protocol (SDP) has been proposed by Casner, “Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth” (see RFC 3556, incorporated herein by reference and available at http://www.ietf.org).
The SDP instance for the particular session may be extended with two additional parameters, where b=RS:<bandwidth-value> and b=RR:<bandwidth-value> specifies the overall sender and receiver report rate, respectively. The per-host allocation and report time interval is determined according to the standard RTCP algorithm.
Multicast Feedback Regulation
The bulk of existing work as considered within the IETF RMT Working Group addresses the problem of suppressing redundant feedback, e.g. negative acknowledgements of lost data packets for reliable multicast transmission. Other multicast applications demand for feedback of the end system with an extreme value according to a particular metric.
The goal of these schemes is to find the receiver with the limiting capabilities (bandwidth) in a multicast session, so that the sender adjusts the transmission rate with respect to this receiver's feedback. End-to-end solutions to both problems usually use different variants of feedback timers or polling mechanisms.
Hardly any existing work deals with feedback regulation for collecting state information of participating receivers in a multicast. One prominent mechanism for video streaming applications based on collecting receiver state information is presented in Bolet et al., “Scalable Feedback Control for Multicast Video Distribution in the Internet” (Proceedings of ACM/SIGCOMM 1994, Vol. 24, No. 4, October 1994). The primary goal of the proposed mechanism is to adjust the sending rate of packets according to the reported state information.
Hence, the set of states a receiver is allowed to report is limited to only three different states. Consequently, this approach is not applicable for regulating feedback of statistics in 3GPP MBMS sessions due to the following problems:
The number of participating end systems has to be discovered by each receiver by means of RTCP RR. This requires each participating mobile terminal (MT, UE) to establish a point-to-point feedback channel to the sender.
The sender would then have to reflect all RRs or summarize them and forward this information on the unidirectional multicast channel. The shortcomings of this solution in the context of a cellular and mobile environment are obviously:                the cost for the establishment and maintenance of the feedback channels (one per MT/UE),        the overhead on the multicast channel generated by the reflected reports, and        the power consumption overhead on the end devices which have to maintain and update state information dynamically.        
Unicast feedback channels might require a significant amount of resources within a cell, e.g. if every user is to have a dedicated uplink channel having for example an individual spreading code. This situation may lead to an increased call blocking and handoff dropping probability in the corresponding cells.
The per-receiver bandwidth bRR is calculated with the standard algorithm as follows:
      b    RR    =      min    ⁡          (                                    avg            ⁡                          (                              P                RTCP                            )                                            T            min                          ,                              B            RR                    n                    )      with the minimum time interval Tmin (e.g. 5 s), the RTCP packet size PRTCP, the overall receiver report bandwidth BRR (3.75% of the RTP bandwidth), and the number of receivers n. The resulting per-receiver bandwidth bRR as a function of the group size is depicted in FIG. 1.Per-receiver Bandwidth as Calculated with the Standard RTCP Algorithm
Due to group dynamics—receivers may join and leave during an ongoing session—the effective per-receiver bandwidth is not known a priori and may vary significantly. In order to avoid frequent re-establishment of feedback channels in order to adapt to the current group size, receiver feedback channels would have to be established with resources reserved to the upper bound, i.e. in the worst case the maximum RR bandwidth. As a consequence, reserved resources for the feedback channels might be used very inefficiently.
The RTCP RR time interval T is calculated by the standard RTP algorithm as follows:
      T    =          max      ⁡              (                              T            min                    ,                      T            calc                          )              ⁣          ⁢  where  ⁣          ⁢            T      calc        =          n      ×                        avg          ⁡                      (                          P              RTCP                        )                                    B          RR                    with the minimum time interval Tmin, the number of receivers n, the RTCP packet size PRTCP, and the overall receiver report bandwidth BRR.
FIG. 2 shows the RR time interval T (calculated according to the equations above) versus the number of receivers n participating in the RTP session. The time interval increases linearly with the number of participating receivers.
To illustrate the quantitative effect, the following example of streaming audio-visual content with a data rate of 64 kbps may be considered. For an average RTCP RR packet size of 120 Bytes and n=100 the report time interval will be calculated to T100=40 s, i.e.; for n=9,000 it already reaches T9,000=3,600 s=1 h.
Following the standard algorithm, receivers schedule their report packets probabilistically within the interval [0.5 T, 1.57 T ] following a uniform distribution. I.e., in the above example the first report packet is expected to be sending after 20 s and 0.5 h, respectively. Obviously this resulting RR time interval T is unacceptable for practical purposes.
As mentioned above, the standard RTCP approach addresses the characteristics of the ASM model, where every end system may send and receive data over a single bi-directional channel and further provides the possibility of loss reporting. However, for 3GPP MBMS services the interval would easily exceed the duration of a session, making reporting useless.
Further it is to be noted that also for broadcast data delivery it may be considered to provide feedback from the receivers of a broadcast service, especially as content based charging may be used also for broadcast data delivery, where the quality of the received content may be crucial for charging. In contrast to subscription based charging where only the fact that a certain service is received is of importance.
The above mentioned RTP and MBMS specific problems may be generalized to multicast or broadcast services received at mobile terminals via an air interface using protocols enabling the provision of feedback from the receiving terminals to the sending source, e.g. a multicast or broadcast server.
In WO 2004/040928 A1 method for reporting for multi-user services in wireless networks is known. The concept of this document is to generate aggregated feedback reports based on the RNC knowledge of the air interface resources in an intermediate network part. RTCP feedback from the terminals can be disabled for the multi-user service, i.e. for all receivers of the multi-user service. In a variation all receivers of the multi-user service may be configured by the RNC to provide event driven feedback. This information from the receivers may also be used in the RNC to form the aggregated feedback.
The method and system proposed in WO 2004/040928 A1 uses the RNC's knowledge on the radio resources of the mobile communication system to generate aggregated feedback reports transmitted to the source of the multi-user service, the server. Thereby the end-to-end concept multi-user service provision is sacrificed as the method proposed in this document requires interactions and data exchange among different layers, for example as the session layer and radio resource control as well as proprietary extensions between radio resource management in the RNC and the intermediate network part to communicate data. These extensions are not feasible if the architecture for providing a multicast or broadcast service should be widely settled.